When a loan application is presented to a lender, the lender decides whether to fund the loan or not. In modern lending systems, this is done by taking data in the loan application, possibly aggregating it with external data from other data sources, and then applying a scoring function to the data to generate a score. Typically, the lender will fund the loan only if the generated score exceeds a certain threshold. Except in extraordinary cases, a computer program located either locally or remotely performs the scoring operation. Similarly, when a collections agent wishes to prioritize defaulted loans upon which they intend to act, they can apply one or more scoring functions to the defaulted loans to generate a score or scores, and perform one or more collection actions to encourage payment based on a prioritization from the generated score or scores. Similarly, when a marketer wishes to determine how best to execute a marketing campaign through one or more media, the marketer can collect data related to all possible targets of the marketing campaign and rank them by applying a scoring function. This helps to optimize the performance of the campaign for the amount of money spent. All of these applications are homologous: an individual or entity wants to make a decision for one or more business items, so the individual or entity passes information through a scoring function that generates one or more scores. The generated score or scores are then used in making the decision for the one or more business items or prioritize actions.
In general, two groups collaborate to develop these scoring functions, a group of modelers (often referred to as underwriters or other names in different contexts,) and a group of programmers (often referred to as software engineers, developers, or similar names.) The modelers, working in a domain-specific language (DSL) or system such as SAS, SPSS, Stata, R, S-plus, MatLab or others, may build a prototype implementation of the scoring function. This prototype can then be given to the programmers, who reimplement the prototype in a general purpose language (GP language) such as C, FORTRAN, Ruby, or C++, before incorporating the implementation into a larger system that delivers scores.
This method of implementation has a number of drawbacks. First, it can require a long period of time to deploy a scoring function, since the reimplementation process is delicate and difficult.
Additionally, the resulting scoring function is relatively difficult to test because tests typically need to be reimplemented in the GP language.
Additionally, DSL's often incorporate algorithms that make the mathematical operations used in the scoring function more stable or accurate. Most GP languages do not include such algorithms, as they make a minor contribution to the uses for which the GP languages are normally applied. Even in cases where programmers have access to tools that implement special purpose algorithms, it can be essentially impossible to guarantee that in all cases the results in the larger embedded system match the results in the prototype scoring function.
Additionally, scoring functions can return unexpected results for reasonable inputs and thus fail to accurately compute solutions. In such cases a final diagnosis of the nature of the failure and its appropriate fix should fall to the group of modelers. If the prototype has been reimplemented, few if any of members of the modeling team will have the sophistication to diagnose any problems with the reimplemented prototype.
Additionally, systems that solve qualitatively different problems (underwriting versus collections versus marketing) will typically have separate implementations. This introduces additional problems, ranging from a lack of shared context (such as the environment the code was written in, including the tools used to write the code and the members of the team who wrote the code) among different programmers, to a lack of common testing infrastructure, even causing potential political strains within an organization due to replication of roles among different units.
By removing the reimplementation process, the drawbacks listed above can be resolved. If an API between the presentation layer and the scoring layer is suitably designed, introducing or upgrading a scoring function can be trivial, since the scoring layer can be easily replaced (if it is a discrete component of the scoring system) or the scoring system can be stopped and restarted with a new scoring function in place. Modelers can debug the implementation of the scoring function, as they wrote it and are therefore familiar with the implementation language and code. Since the scoring function runs in the DSL itself, the scoring function will continue to use any of the special computational or algorithmic features described in paragraph, above.
The division of the main API into two layers makes the process of building a client for a given system more straightforward and reproducible, particularly since many of the interactions between the kernel and the client level are human readable and can thus be read by non-coders. This exposes most of the internal structure of the client layer in an easy to understand medium, making it easier to share knowledge among and between developers and teams, reducing the cost of building new client layers, and thus reducing costs overall.